…ent (tinyhumansai#4254, backend)

Rework of tinyhumansai#4413's backend onto post-tinyhumansai#4399 code. tinyhumansai#4399 deleted the original
classification hook (session/agent_tool_exec.rs) and the ProgressReporter
trait; the tool loop now runs on the tinyagents crate, so the hook is
re-homed on the adapter seam.

- New `src/openhuman/tool_status/` module: `classify(error_text, timed_out)`
  and `describe(class)` map a tool outcome to a `ClassifiedFailure`
  (class + category + plain-language cause + next action). Pure, unit-tested
  (16 tests: all classes, timeout/unknown/precedence, category mapping,
  recoverability).
- `AgentProgress::ToolCallCompleted` + `WebChannelEvent` gain a `failure`
  field carrying that classification to the chat "View processing" timeline.
- Core hook + latent-bug fix: the crate's `AgentEvent::ToolCompleted` carries
  only call_id + tool_name, so the bridge previously hardcoded `success: true`
  (a failed tool never surfaced). `ToolOutcomeCaptureMiddleware::after_tool`
  now classifies each result and writes a `call_id → (success, failure)`
  side-channel (mirroring the existing `ToolNameMap`); the bridge reads it to
  emit real `success` + `failure`. Absent entry falls back to `(true, None)`.
- `progress_bridge` serializes `failure` onto the `tool_result` socket event
  and the run ledger.

Backend only. The frontend consumer (chat timeline "why / next" render) and
i18n keys are a companion — they rebase cleanly onto current `main` from
tinyhumansai#4413 (only the Rust hook conflicted with tinyhumansai#4399), so they are not re-included
here to avoid reverting unrelated locale drift.

NOTE: the middleware-before-event ordering that populates the side-channel is
crate-internal; the fallback keeps behavior no worse than before if the event
is ever projected first. Needs runtime validation once tinyhumansai#4442 lands (drive a
deliberately-failing tool and confirm `success:false` + `failure` on the wire).

…tatus needles

Addresses CodeRabbit review on tinyhumansai#4445:
- Bare HTTP 403/Forbidden (e.g. Gmail/Composio "403 insufficient authentication
  scopes") was classified as BlockedByPolicy, telling the user to change Agent-access
  settings and marking it non-recoverable. It's an external authz failure → now
  BadCredentials (reconnect / grant scopes). OpenHuman's own policy blocks are tagged
  upstream with POLICY_BLOCKED_MARKER (never reach this heuristic); the OpenHuman-specific
  'forbidden path' marker stays policy, checked before credentials so it still wins.
- contains_any did unbounded substring matching, so '403'/'401'/'50x' false-matched
  inside longer digit runs (a '403' in '14033', a port, a byte count, a timestamp).
  New contains_code() requires non-digit boundaries on each side.
- Regression tests: external 403/401 → credentials, 'forbidden path' → policy,
  embedded 403/503 in longer numbers → Unknown, standalone 503 → service.

The tool-failure feature added AgentProgress::ToolCallCompleted.failure; an
integration test (tests/, a separate compilation unit not covered by
`cargo check --lib`) constructed the event without it, failing the Rust Core
Coverage job (E0063). `cargo check --tests` is now clean.